Electronic data capture and verification

ABSTRACT

Apparatus for automatically building an electronic form for presentation to a user during a data capture process segregates the data capture intent behind the form from the presentation and execution of the form to a data capture user. In this way, the data capture process, including generation of the form and display of user input prompts, can be carried out on any computing platform independent of the system used to generate a data capture definition file that specifies the intent of the data capture requirements. The specification of data elements required during data capture, each having a type specification and a logical relationship relative to other data elements in a hierarchical structure are defined in a data capture definition file in a predetermined format. A data capture process executes the data capture definition file and automatically generates a plurality of visual displays for presentation to a user, each input screen comprising a plurality of user input areas corresponding to the data elements and physically positioned on the screen in a manner corresponding to the defined logical hierarchical structure.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a 371 of PCT/GB03/02180 filed on May 20, 2003, whichclaims priority from United Kingdom patent application number 0212934.4filed on Jun. 6, 2002, both of which are hereby incorporated herein byreference in their entireties.

FIELD OF THE INVENTION

The present invention relates to methods and apparatus for enablingelectronic capture of data input by a user and data exchange betweensystems. In particular, the invention relates to methods and apparatusfor the automatic generation and presentation of forms for display on acomputer monitor, which forms guide and prompt a user to enter data intoappropriate fields in the displayed form. The invention further relatesto methods and apparatus for automatically testing the data being inputfor compliance with predetermined validation criteria, and rule-baseddetermination of subsequent action (such as determination of the natureof a subsequent screen display) based on the data input. The inventionfurther relates to methods and apparatus that can be used in dataexchange between systems whereby validation criteria and rule basedactions can be applied during data exchange.

BACKGROUND OF THE INVENTION

Many organisations throughout industry and commerce, such as banking,insurance, finance, healthcare etc, have a common requirement to receiveand process complex data relating to individual customers that theyserve. For example, insurance organisations need to capture largequantities of personal information from individuals, which informationinclude names, addresses, ages, personal circumstances, lifestyledetails, health details, insurance cover requirements, and so on.Conventionally, the most convenient way to do this has been by the useof forms, which can be presented in hard copy, or preferably presentedon a computer monitor, enabling direct capture of the entered data ontocomputer storage media.

Many of the data values entered by a user actually determine the typeand range of further questions that must be asked of the individual, andthus it is desirable that the computer system verify the accuracy of thedata, in real time, during data entry, and then use a rule-based systemto determine further forms for presentation to the user based on theprior data entry.

While this type of form-based data entry and capture is a veryconvenient and accurate method for the user, the initial set up costsfor providing suitable, well-presented forms with underlying datacapture logic that exactly match each organisation's specific datacapture requirements is a complex task that requires advancedprogramming skills.

Each form must be specifically customised in terms of the presentationand content of questions or prompts to be displayed to the user, theformat of data to be received, the validation rules for checking thedata as it is being entered, and rule-based actions executed inreal-time which determine outcomes based on the data values received,such as determining further data capture requirements based on thereceived data.

The data capture logic must not only determine the information contentand layout of the forms presented to the user, the data validationfunctions and the rules for use during form execution, but also mustdefine how the data should then be exported to (eg. mapped into) theorganisation's database, or exchanged with other databases. Clearly, thepersons who are best placed to comprehend and define the organisation'sdata capture requirements (ie. the “business experts” who have detailedknowledge of the business requirements behind the data) are not likelyto have the advanced programming skills necessary to implement theelectronic data capture functions.

There are a wide variety of prior art computer applications which enablea person (acting as a form architect) to define an electronic datacapture or exchange.

Many of these prior art systems provide WYSIWYG-type form building ordata exchange capabilities intended for backoffice, client/server ortraditional desktop environments, and may include facilities to definethe function—ie. the data validation and rule based actions.

Some prior art applications allow a data model to be defined, enablingthe data capture to be contained, transported and exchanged according toa predetermined standard.

Some prior art applications provide a means of central control wheremultiple users have assigned roles to manage the application usage.

Additionally, there are tools and utilities available, which can be usedto define an electronic data capture or exchange, but these do notprovide interfaces to abstract the form architecture from the underlyingtechnology or expertise required in order to utilise the data capture orexchange.

Thus, there are a significant number of problems with the prior artapproaches.

i) The WYSIWYG-based applications are prescriptive in their approach toform design. As shown in FIG. 7, an architect 8 defines data capture byuse of a visual form 1 with positional (x-y) co-ordinates, upon whichthe architect graphically places the data items to be captured, ie.textboxes, radio buttons, drop down lists, menus etc.

The problem with this approach is that the architect is graphicallydesigning a form 1, according to a specific target of execution 22 (ie.a single data capture requirement, rather than an approach of intentwhere the architect 8 merely specifies what data is to be captured orexchanged (ie. the intent).

ii) In the prior art, the target execution of a data capture and/orexchange built using a WYSIWYG-based application is restricted to thespecific technology or platform 22 in which the application operates. Asillustrated in FIGS. 5 and 6, if a data capture/exchange is required forexecution across multiple technologies/platforms, in the prior art, thearchitect is required to repeatedly define the form 1, function 2 anddata model 3 container, using a different application for each singlespecific execution purpose 22 technology platform required. As shown inFIG. 5, each implementation of a form requires a separate build processfor each different technology/platform, even though there might only beone set of data capture requirements, rules/function and data model.

In this regard, XML tools and utilities can be used to create a singleXML document to achieve this purpose, but this requires that thearchitect possesses the necessary XML technical skills and understandingof the XML dialect and schema employed. The architect 8 is not providedwith an environment with which they can specify their requirements ofthe data capture and/or exchange.

iii) Using WYSIWYG-based applications, a defined data capture executedas a form cannot also be used as part of an automated data exchangemechanism between systems. Some of these applications can be used tocreate data exchange mechanisms, or components thereof, but this is aseparate function, and an existing defined data capture plays no part inthe construction or use of the data exchange, requiring the datadefinition 21, function 2 and data model 3 to be redefined.

In this regard, XML tools and utilities can be used to create a singleXML document to achieve this purpose, but this requires the architect topossess the necessary XML technical skills and understanding of the XMLdialect and schema employed. The architect 8 is not provided with anenvironment with which they can specify the requirements of the datacapture and/or exchange.

iv) None of the prior art described above provide the ability for thearchitect to construct a form according to an XML form definitionstandard, and validate that form against it, without requiring theappropriate XML technical skills and knowledge of the XML dialectemployed.v) None of the prior art described above provide the ability to automateform construction based on an XML form definition standard, or partsthereof. The architect has to manually construct the form. Someapplications will automatically generate a form based on a databasetable definition or similar, but this does not constitute a formdefinition standard, and the automation uses the entire table or model,rather than selected part(s).vi) None of the prior art described above, provide the ability for thearchitect to define the data model container for the form or to setconditions against which the form data is bound to the data model,without requiring appropriate XML technical skills and knowledge of theXML schema employed.vii) None of the prior art described above supports the specificcombination of creation, use, re-use and propagation of entire or partforms as templates, by multiple users with assigned roles and rights,utilising locking at form level to prevent conflicts.

SUMMARY OF THE INVENTION

Embodiments of the present invention may provide a form design tool thatautomatically generates an appropriate form layout for presentation to auser during a data capture process, based on an architect'sspecification of data items, validation criteria and rule-basedexecution criteria.

Embodiments of the present invention may also provide a softwareapplication that enables an architect to define his or her data capturerequirements, the criteria for validation of the data and the rule-basedactions governing outcomes based on the data input, to create a datacapture definition file that can subsequently be used by apresentation/execution program to automatically generate a data captureform layout for presentation to a user, and execute data capturetherefrom, in which the data capture definition file is platformindependent.

Throughout the present specification, the expression “form” is intendedto cover one or more of a series of computer-generated displayspresented to a user, containing suitably presented data input areas suchas text fields, check boxes, drop down menus, selection menus and thelike. The expression “architect” is intended to refer to the persondesigning a form or, in the context of the present invention, providingthe data capture requirements that will result in automated building ofthe form. The expression “user” is intended to refer to the personentering data during a data capture session using the formsautomatically generated on screen.

In accordance with embodiments of the present invention, the process ofdefining the “intent” of the forms—ie. the process of specifying thedata to be captured, by a business expert, can be divorced from thedefinition of the actual form layout. Also, the form layout can beeffected independently and automatically when the specification of thedata to be captured has been provided in a suitable hierarchical manner.

A software application program may be provided to enable an organisationto centrally define, manage and maintain their intent for electronicdata capture requirements, which is effected by means of documentsconforming to predetermined standards that can be deployed in multipleenvironments, where they are executed as forms.

According to one aspect, the present invention provides apparatus forautomatically building an electronic form for presentation to a userduring a data capture process, comprising:

-   -   means for receiving as input a specification of data elements        required during data capture, each data element having a type        specification, and a logical relationship relative to other data        elements in a hierarchical structure;    -   means for generating, from said input, a data capture definition        file providing said specification of data elements and said        hierarchical structure in a predetermined format; and    -   means for receiving said data capture definition file and        automatically generating a plurality of visual displays for        presentation to a user during execution of a data capture        process, each input screen comprising a plurality of user input        areas corresponding to the data elements and physically        positioned on the screen in a manner corresponding to the        defined logical hierarchical structure.

According to another aspect, the present invention provides apparatusfor generating a data capture definition file for defining data elementsrequired from a user during a data capture process, comprising:

-   -   means for receiving as input a specification of data elements        required during data capture, each data element having a type        specification, and a logical relationship relative to other data        elements in a hierarchical structure, said type specifications        and said hierarchical structure being usable for automatically        determining a physical layout of visual displays for        presentation to a user during a subsequent data capture process;    -   means for associating, with said data elements, a set of data        validation requirements for validating data captured in respect        of each of the data elements;    -   means for associating, with said data elements, a set of rules        for execution during a subsequent data capture process, for        further enabling automatic determination of a physical layout of        the visual displays to be presented to a user during said        subsequent data capture process based on values of data captured        during said data capture process;    -   means for generating said data capture definition file providing        said specification of data elements, said hierarchical        structure, said data validation requirements and said set of        rules in a predetermined format for subsequent execution by a        data capture process.

According to another aspect, the present invention provides an apparatusfor generating a generating an electronic form for presentation to auser during a data capture process, the apparatus comprising:

-   -   means for receiving as input a data capture definition file in a        predetermined format providing a specification of data elements        required during data capture, each data element having a type        specification and a logical relationship relative to other data        elements in a hierarchical structure;    -   means for automatically generating a plurality of visual        displays for presentation to the user, each visual display        including a plurality of user input areas and user prompts        relating thereto corresponding to the data elements, each being        physically positioned on the displays in a manner corresponding        to the defined logical hierarchical structure.

According to still further aspect, the present invention provides amethod for building an electronic form, a method of generating a datacapture definition file, and a method of generating an electronic formfor presentation to a user as carried out by the apparatus definedabove.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present invention will now be described by way ofexample and with reference to the accompanying drawings in which:

FIG. 1 shows a schematic diagram at system level illustrating theenvironment of a form builder according to the present invention;

FIG. 2 shows a more detailed schematic diagram of the form builder andexecution modules according to the present invention;

FIG. 3 shows a schematic diagram of the data capture definition filebuilding operation;

FIG. 4 shows a schematic diagram of the data capture definition filebuilding operation including automatic section and element generation;

FIG. 5 is a schematic diagram of a prior art platform dependent formbuilding operation;

FIG. 6 is a schematic diagram illustrating prior art data capture anddata exchange operations;

FIG. 7 is a schematic diagram of a prior art graphical form designprocess;

FIG. 8 is a screenshot of a first stage input box in a new formdefinition process;

FIG. 9 is a screenshot of a form definition box for specifying sections,sub-sections and elements that will make up a form;

FIG. 10 is a screenshot of a form definition box indicating thehierarchical structure of sections, sub-sections and elements that makeup a form;

FIG. 11 is a screenshot of an input box for defining a new section inthe form structure hierarchy of FIG. 10;

FIG. 12 is a screenshot of an input box for defining a new data elementin the form structure hierarchy of FIG. 10;

FIG. 13 is a screenshot of an advanced input box for defining a newelement in a form structure hierarchy of FIG. 10;

FIG. 14 is a screenshot of an input box for defining a new rule in aform structure definition process;

FIG. 15 is a screenshot of an input box for defining actions under arule in the form structure definition process;

FIG. 16 is a screenshot of an input box for defining event triggers forrules in the form structure definition process;

FIG. 17 is a screenshot of a form structure definition box indicating abinding or mapping of each of the hierarchical form sections,sub-sections and elements with a corresponding data exchange destinationentity;

FIG. 18 is a screenshot of an input box for adding a new binding entityused in the data exchange definition;

FIG. 19 is a screenshot of an input box for defining binding conditionsin the data exchange definition;

FIG. 20 is a screenshot of an input box for defining attributes ofbinding entities in the data exchange definition;

FIG. 21 is a screenshot of an input box for binding an evaluationexpression to an element in the hierarchical form definition and dataexchange definition;

FIG. 22 is a screenshot of a template definition box for specifyingsections, sub-sections and elements that will make up a template form;

FIG. 23 is a screenshot of a template definition box indicating thehierarchical structure of sections, sub-sections and elements that makeup a template form;

FIG. 24 is a screenshot of a propagation instruction box definingactions to be taken on change in a template;

FIG. 25 is a screenshot of a template change update box used to alert anarchitect of changes to a template;

FIG. 26 is a screenshot of an impact analysis box to indicate the impacton existing forms resulting from changes to a template;

FIG. 27 is a screenshot of a preview box illustrating the sections,subsections and elements in a selected form definition;

FIG. 28 is a screenshot of an export validation control box;

FIG. 29 is a screenshot of an export destination definition box for usein the data exchange definition;

FIG. 30 is a screenshot of an import destination definition box for usein the data exchange definition;

FIG. 31 is a screenshot of a form definition release control box;

FIG. 32 is a screenshot of a form destination release definition box;

FIG. 33 is a screenshot of a document permission properties input boxfor entering ownership and use properties of form definition files;

FIG. 34 is a screenshot of a trigger list display box showing alltriggers defined in a form definition;

FIG. 35 is a screenshot of a rule list display box showing all rulesdefined in a form definition;

FIG. 36 is a screenshot of a rule repair input box for correctinginvalid rule assignments;

FIG. 37 is a screenshot of an initial user input screen for datacapture, showing form sections to be filled in by the user;

FIG. 38 is a screenshot of a user input screen for providing as firstinput a number of applicants;

FIG. 39 is a screenshot of a user input screen resulting from completionof data entry in the screen of FIG. 38;

FIG. 40 is a screenshot of the user input screen of FIG. 39, butpresented as an on-line web page;

FIG. 41 is a screenshot of a user input screen for providing as inputdata corresponding to a general questions section of the form;

FIG. 42 is a screenshot of a user input screen resulting from input“yes” to one of the general questions of FIG. 41;

FIG. 43 is a screenshot corresponding to FIG. 41, but presented as anon-line web page;

FIG. 44 is a screenshot corresponding to FIG. 42, but presented as anon-line web page;

FIG. 45 is a screenshot of an alert box generated during datavalidation;

FIG. 46 is a screenshot of a completion control box presented after dataentry;

FIG. 47 is a screenshot of an alert box corresponding to that of FIG.45, but presented as an on-line web page; and

FIG. 48 is a screenshot of a completion control box corresponding tothat of FIG. 46, but presented as an on-line web page.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

With reference to FIGS. 1 and 2, the invention provides a softwareapplication 30 which enables an organisation to centrally define, manageand maintain their electronic data capture requirements in predetermineddata capture definition file formats, which are preferably effected asself-contained XML documents 17, although other standard existing orfuture document formats could also be used.

Each data capture definition file 17 consists of a form definition 1, afunction definition 2 and a data model definition 3, that can bedeployed in multiple environments, where they are executed as formsand/or as part of a data exchange. In particular, the data capturedefinition file 17 comprises a specification of data elements that arerequired for data capture, each data element having a type specificationthat specifies the type of data to be collected, and an indication ofits logical hierarchical position relative to other data elements in ahierarchical structure.

The application 30 can be fully operated by ordinary persons 31, actingas form architects having no particular technical knowledge orunderstanding of programming, including XML and scripting technologiesinvolved. The application 30 can be installed and maintained withminimal or no technical support.

Furthermore, the application 30 enables the data capture to be definedin a standard manner, using a form definition standard 4. The function 2is defined as data validation and rules assigned to events, and the dataitself to be contained within a data model 3 for storage, transport andexchange between systems 18, 19, 20 that offer interfaces adhering tothe same model.

The application 30 supports multiple architects 31 with assigned rolesand rights, and utilises locking 32 at document level to preventconflicts. To enable joint construction and re-use, templates can becreated, used and propagated within other documents—as part or whole.

The application 30 preferably uses a database repository 34 to store thedocuments 17, 33 that collectively form an organisation's data capturerequirements.

By means of user accounts 35, passwords, groups, roles and rights(assigned to individual documents 33), the application 30 preferablyenforces security to support multiple architects and provide controlover rights.

Preferably, an administrator account 40 exists to administer thesecurity, with the ability to create, delete or edit user accounts 35,groups or roles, reset passwords, change document ownership or unlock alocked document.

To prevent document change conflicts, the application 30 preferablyemploys document level locking. In order to edit a document, thearchitect 8, 31 must ‘lock’ the document 17, 33 for editing. Whilst‘locked’, only that architect is able to make and save changes. Otherarchitects can read the document whilst it is locked for editing.

Preferably, the document creator 8, 31 is the document owner. Only thedocument owner can delete the document and change the rights that otherusers have over the document.

In order to keep track of document history and releases, preferably theapplication 30 supports versioning and revision. When a document 17, 33is versioned or revised, a read-only copy is made at that point and theoriginal document major or minor version number is increasedrespectively.

Additionally, the application 30 preferably provides the followingfacilities at document level, to aid management of an organisations datacapture requirements:

-   1. Create a new document-   2. Create by copy—a document can be copied as a new document-   3. Rename a document-   4. Import/export or release a document-   5. Preview a document—test deployment of a document in a data    capture operation

The process of defining a data capture/exchange consists of building thethree main components contained within the data capture definition file17, preferably an XML document, for deployment by an end user 18 via apresentation/execution layer 7.

The data capture definition file comprises a form definition 1 whichcomplies with a form definition standard 4. The architect 8 specifieshis or her intent 6 for the contents and hierarchical structure of theform. The contents and structure comprise a definition of the data itemsto be collected in execution of the form, each data item having a datatype, and a relative position in a hierarchical structure comprisingsections and sub-sections. The form definition does not define thelayout of the data as it will be presented on a user input screen fordata capture, since this aspect will be interpreted and executed 10 atthe presentation layer 7. A significant feature of thispresentation/execution layer 7 is that, because it operates upon a datacapture definition file 17, 33 that conforms to a predeterminedstandard, it can be operated on multiple technologies/platforms 9.

The function definition 2 in the data capture definition file 17, 33includes the data validation, rules and events that define the functionof the form during its execution either at the presentation/executionlayer 7, or as part of a data exchange 19, 20.

The data model container definition 3 indicates how the data captured isto be formatted in the output resulting from data capture. This adheresto a data model standard 5 used for storage, transport or exchangebetween systems that offer interfaces adhering to the same model.

With reference to FIG. 3, the application 30 enables definition 15 ofthe form structure and content 14 of the data capture/exchangerequirements according to the form definition standard 4. The definitionincludes a plurality 13 of data elements in sections and sub-sectionsdefining a hierarchy to the data elements. It is this hierarchy thatwill be used, in part, by the presentation/execution layer 7 todetermine the final layout of the forms presented to the data captureend user 18.

The architect 8 is abstracted 12 from requiring any knowledge orunderstanding of the form definition standard 4 by means of an interfacethat enforces conformity through a validation process 11, and onlypresents the sections and elements contained therein for selection. Whenadding new sections or elements 13, the architect 8 can specify the typeof section, ie. a column section, and the data element type. Anon-exhaustive list of examples of data types is: text, number,currency, date, list, combo-box, caption, option, checkbox, yes/no,radio button, popup, or picture.

Additionally, data elements can have characteristics that can bedefined. A non-exhaustive list of possible data element characteristicsis: precision, default value, prefix/suffix, width, height, currency,read only or leading zeros.

All of these types and characteristics are preferably defined by theform definition standard 4.

With reference to FIG. 4, the application 30 preferably enablesautomated generation 16 of the data capture definition file 17, 33, or apart thereof, based on the form definition standard 4.

In this manner, the architect 8 is able to specify 15 the intent 6 forthe data capture requirements according to the form definition standard4. The architect 8 does not specify how the form is presented, sincethis interpreted from the data capture definition file 17 duringexecution 10 at the presentation layer 7, which can be across multipletechnologies/platforms 9.

During execution 10 of the form, the data validation, rules and eventsdefine the function of the form—the operation.

The application 30 preferably enables definition of rules and theirrespective rule functions 2 by providing a rule builder interface thatenables an architect 8 to create complex rule actions and conditions,and assign them to the events (eg. when the value of a data element isprovided), without requiring any knowledge of the underlying script thatis generated.

Basic data validation functions can be assigned to the individualelements in the same way the element type and characteristics aredefined, including such items as mandatory, max length, minimum ormaximum value (as determined by the form definition standard 4).

The application 30 preferably enables the storage, transport or exchangeof the data capture, by enabling the architect to bind the form elementsto a defined XML data model. During the executable lifecycle of theform, the data captured is stored within the data model 3, where ruleactions can be effected upon it, and data transport or exchange can takeplace to/from external data sources 19, 20 also adhering to the samedata model. Specification of the data model construct, is stored withinthe XML document as bindings.

The application abstracts this construction, by providing an interface,which enables form elements being bound to the entities and attributeswithin the data model, but does not require the architect to have anyknowledge or understanding of the underlying XML and schema employed.Additionally, by means of a condition builder interface, the applicationenables the architect to specify logical conditions that must evaluatetrue during form execution, in order for the specified elements of theform to be bound to the data model.

For data import, Xpath or XSL queries are required that specify the dataretrieval mechanism from the data source. To aid the architect in theconstruct and testing of these queries, the application 30 preferablyprovides a Query Builder tool.

The application 30 preferably enables joint construction and re-use of adata capture (or part thereof) by multiple architects, by the use oftemplates.

An existing document 17, 33 of part thereof, can be selected to form anew template, or if desired, a template can be created and built from anempty, new template. A template is preferably owned and modified by thetemplate creator. A template can preferably be used in the constructionof a document, to form part of that document, or the whole. A templatecan preferably be used in the construction of another template, andthere can be several layers of nested templates. When a template is usedin another document or template, it is known as a template copy, whichis linked to the original.

When a template is modified, all documents or other templates that usethe modified template will preferably be automatically flagged forchange. The next time these documents or other templates are accessed,the architect 8 is notified of the changes made to the originatingtemplate, to which they can accept or reject those changes to bepropagated to the template copy within the receiving document ortemplate currently being accessed.

A template copy in another document or template can be selected to‘break link’ with the original template. When selected to ‘break link’the template copy is no longer identified as such and any changes madeto the original template are no longer flagged for propagation in thatdocument or template.

To aid control and management of templates, an impact analysis facilitymay be provided on templates, which facility reports the names of allthe documents and other templates that have copies of that template.

The application enables the data capture requirements as self-containedXML documents, to be transferred between separate installations of theapplication, using an import and export facility.

During import the document is validated against the form definitionstandard 4 and data model standard 5, and any identified errors arelisted for the architect to correct, using the application 30.

Upon selecting to export a document, it is first validated against theform definition standard 4 and data model standard 5, to ensure itconforms. If it passes validation, the data capture requirements for thespecified document containing the form, function and data model areextracted from the central database repository 34 as a self-containedand portable XML document 17, 33, which can be imported at anotherinstallation of the application, or the same installation as aduplicate.

When a data capture definition is completed and ready for deployment, itcan be released as a self-containing XML data capture definition file(document), consisting of the form, function and data model. The releaseprocess first validates the document against the form definition anddata model standards, to ensure it conforms. If it passes validation,the form, function and data model for the data capture, are extractedfrom the central repository as a portable self-contained XML document.

As shown in FIG. 2, the self-contained XML document 17 can be deployedfor execution 10 at the presentation layer 7 for an end-user 18 and/oras part of a data exchange 19, 20 across multipletechnologies/platforms/environments 9.

A self contained XML document 17 released from the application can beexecuted at the presentation layer 7 for display to a data capture user,for data capture 18, using any suitable host runtime element. There area number of these available, operating in differenttechnologies/environments, such as standalone desktop computer, andclient/server solutions in different technologies (eg. server side Java,client side browser, or server side Microsoft, client-side browser). Theclient-side browser capability of the runtime element does not requireany components to be downloaded for data capture—it is purely html andscript sent directly from the server. This enables deployment of thepresentation/execution layer 7 across multiple devices and platforms,such as internet kiosk, hand-held device, etc. Thus, the defined datacapture requirements encapsulated as a self-contained XML document 17can be executed 10 across multiple technologies/platforms 9.

The runtime presentation/execution layer 7 interprets the data capturedefinition file 17 for presentation to the end-user 18, at which timethe actual display characteristics such as form layout and position ofall data elements are determined according to the hierarchical structuredefined in the data capture definition file. The presentation/executionlayer also executes the function defined in the data capture definitionfile, which defines the operation and interaction with the end-user 18.

As data is captured from the form 1 and function 2, it is stored in thedata model 3, which can be exchanged 19, 20 with other systems, whichoffer interfaces that adhere to the same data model definition.

In the same manner that the runtime presentation/execution layerexecutes 10 a self-contained XML document 17, it can also execute 10 aspart of a data exchange 19, 20. This can occur in place of, or inaddition to the presentation layer 17.

The runtime host described above provides interfaces that enable thedata capture stored in the data model 3 to be transferred to an externalfile system or message queue. In similar fashion, the data model 3 canbe pre-populated from an external file system or message queue.

In this manner, the XML document can be executed as part of a dataexchange whereby data can be imported from an external data sourceand/or the data capture, and exported to another external data source.

An exemplary sequence of generation of a data capture definition filesuitable for generation of a form during execution of the data captureprocess will now be illustrated.

As shown in FIG. 8, when a new data capture definition file (referred toin the illustrations as a PAC—“Product Application Component), iscreated by an architect 8, they first specify the name 81, title 82 andXML standards 83 employed—eg. the ISML DTD standard and the message(output) standard. Optionally, they can also specify control dates84—effective & expiry, product type/sub-type, product provider,associated documents (for printing) and whether it is for test purposes,in an input box 80.

With reference to FIG. 9, in a second input box 90, in the main window91 on the right, the architect 8 can define the sections, sub-sectionsand data elements in the sections and sub-sections that will make up thedata capture form, by use of context sensitive menus 92.

With reference to FIG. 10, the content and structure of the form forpresentation to a user during a data capture process is represented tothe architect in display box 100 as a hierarchy tree 101, which isconstantly updated as sections 102, sub-sections 104 and elements 103are created. The hierarchy tree 101 is a logical representation of therelationship between data elements 103 and their respective sections 102and sub-sections 104 which will be used to determine the layout ofvisual displays presented to a user during a data capture process.

The hierarchy tree 101 can be used to navigate the sections 102,sub-sections 104 and data elements 103, any of which items (referred toas “node”) can be selected by the architect to view or set properties ofthat node, and perform functions. Examples of such functions include:add new section or element, copy item, paste item, delete item, maketemplate, create or assign rules to triggers/events that occur as thedata capture process is executed.

With reference to FIG. 11, to create new sections and sub-sections, thearchitect selects the type of section—either a main section, sub-sectionor variant—to bring up a new section input box 110, in which may bespecified a section name 111 and a section title 112.

Main sections can be added to the form root, sub-sections and variantsto main sections.

The input box 110 may also be used by the architect to specifyattributes of the section, such as style type 113 which will affect thestyle of presentation of the section to the user during the data captureprocess.

With reference to FIG. 12, the input box 120 for adding an element isdescribed. The architect 8 selects the respective section or sub-sectionthat they wish to add an element to, and using the context sensitivemenu, select to add a new element.

Each element is given a title 121, and a question or prompt 122 thatwill be displayed to the user during the data capture process. Elementscan be of various types, including text, number, yes/no, lookup (list),etc., and mandatory and default values can also be specified.

With reference to FIG. 13, an advanced input box 130 for element entryis shown. Input box 130 is called by using the advanced tab 124 in theinput box 120 (FIG. 12). In advanced input box 130, the architect canalso specify advanced attributes 131 of the prompts displayed to theuser during the data capture process, such as: width, prefix, suffix,height, minimum and maximum values, read only, etc.

Again using the context sensitive menu 92 from a selected item in thehierarchical tree 101 (eg. section 102 or element 103), the architect 8can call up a rule creation box 140 to create rules and assign them tothe triggers or events that occur when the data capture process isexecuted, such as form load, element change, section enter/leave, etc.This defines the form function 2.

Rules take the form IF the condition is true, THEN perform theseactions, ELSE perform these different actions, as defined in the IF THENELSE boxes 141, 142, 143. Rule conditions 141 can have multiple actions142. Further options are available, such as disable rule 145, validaterule 146—to check the rule logic is valid, and view triggers 147—to seewhich events (triggers) the rule is assigned to.

As shown in FIG. 15, a rule action edit box 150 enables the setting ofrule actions 151 which include: set a value to an element, perform afunction (such as validate a postcode or make an external call forinformation or validation), enable/disable, hide/show, display a messageor warning, execute another rule, etc.

Rules are assigned to triggers (events) by first selecting the eventassociated with the section, element or form, such as Formload, sectionenter/leave, element change, etc; and then specifying the rule to betriggered when the event occurs in real-time as the form is executedduring the data capture process. FIG. 16 shows a viewing and editing box160 for triggers and their properties. An event (trigger) can havemultiple rules assigned listed in window 161 (with priorities set todefine the order of execution), and a single rule can be assigned tomultiple events (triggers) as required.

Forms can be bound to a standard data model, so that the captured data(referred to as the message) can be easily exchanged between systemsusing the same data model. Within the application 30, the main controlbox 100, also now shown in FIG. 17 as control box 170, can also display(by using the bindings tab 171, the bindings for each data item with anexternal data model. The architect defines the bindings using contextsensitive menus.

The data element bindings 172 are also displayed in a hierarchical tree173, consisting of the message entities, eg. personal client 174, andthe message attributes, eg. home address. The hierarchical tree 173 canbe used to navigate the data element bindings, where any item (referredto as node) can be selected to view or set properties, and performfunctions, such as add new entity or attribute, copy, paste, delete,etc.

The process of creating the bindings 172 consists of defining themessage entities, eg. personal client, and then mapping the dataelements 103 as presented on the form displayed during data capture tothe attributes of the message entities, eg. mapping home address fromthe personal details section in the form to the home address attributeof the personal client entity.

The selected message standard will contain a number of entities, whichrepresent the topic or subject of data, eg: personal client. Thearchitect can select, using box 180 in FIG. 18, to add an entity 181from the list of available entities 182 within the message standard anddefine properties. If the message is hierarchical, then the application30 will preferably only allow the architect to select the entitiesapplicable to the position in the hierarchy.

The architect can specify a condition 183 upon which the entity 181 isbound to the form, eg: IF Age is less than 70 THEN bind the entity tothe form. Complex binding conditions can be created using logical ANDand OR conditions, using the add new condition box 190 in FIG. 19, eg.IF the Age is less than 70 OR the Age is greater than 25.

Each entity in the message standard employed, has a set of definedattributes, eg. in the example of the personal client entity, oneattribute is the home address, another is surname, etc.

As shown in FIG. 20, the architect can select an entity 172, 201 (fromthe bindings tree 173) and, using the bind attribute instance box 200,add relevant attributes 202, and define the form element(s) to bind.

With reference to FIG. 21, optionally, attributes 202 can be bound to anexpression 211 instead of directly to a form element, eg. the ageattribute could be bound to an expression—calcage (date of birth), usingexpression definition box 210.

In a preferred embodiment, templates form an important role in thecreation and maintenance of data capture definition files, because theycan greatly reduce the effort to build and maintain them, whilstenabling multiple architects to work on the same data capture definitionfile.

A template is a master copy of a part (or can be entire) data capturedefinition file, such as personal details. The template can be copiedinto existing data capture definition files, to form part of that file,or into another template to form part of that template, and so on.

When a template is copied into another data capture definition file ortemplate, it is linked to the original so that when changes are made tothe original template, they can be propagated to the copies that existfor other data capture definition files.

Templates can be created in any combination of the following ways.

1. In exactly the same method as creating a normal data capturedefinition file, described above in connection with FIG. 10, except thatthe template is created using the template tab 221 in window 220 (FIG.220) to select a list 222 of templates. The hierarchical tree 223 of theselected template is displayed in the right hand window.2. By making a template from an existing section or element by selectionof part of a tree 101.

A template may be copied into a form or other template, by simplydragging the template from the left hand window to the form/template inthe main window. The template becomes part of the form/template, but isdistinguishable by a different colour as shown in FIG. 23.

When changes are made to the original template, the changes are markedfor propagation so that other data capture definition files or templatesthat use the template are notified of the changes and can receive thosechanges. These are shown to the architect in a propagation box 240.

When a data capture definition file is accessed that uses a changedtemplate, the architect is notified of the changes and can accept orreject them using a change control box 250 in FIG. 25.

When making changes to templates, in the preferred embodiment an impactanalysis box 260 is available to determine the impact the changes willmake by listing the affected forms and templates.

A template contained within a data capture definition file or othertemplate can have it links broken form the original template so thatchanges are not propagated. When a template within a data capturedefinition file or other template ‘breaks links’ with the original, itis no longer a template and appears in the same colour as the rest ofthe form content.

In the creation or maintenance of an existing form, there are a numberof features and functions available to the architect.

As shown in FIG. 27, in the left hand window 271, a current list ofexisting defined data capture definition files 272 are listed, which canbe selected to perform form level functions. Ability to perform thesefunctions preferably depends on whether the selected data capturedefinition file is locked for editing (possibly by another user), theuser's rights, and the rights set on the form by the form owner/creator.

Any existing data capture definition file can be copied in its entiretyas a new file, which can be easily edited as required, using a copyfunction.

The selected form can be versioned (eg. a major version numberincreased) or revised (minor version number increased). In both cases,the data capture definition file is copied, and the new copy has a newerversion or revision number.

The selected data capture definition file can be locked for editing ifunlocked, or unlocked if locked, so that others may edit it.

The selected data capture definition form may be displayed in tree view101 in the right window (as shown in FIG. 10), where the contents andproperties of the form can be viewed, and (if locked for edit) edited.

Alternatively, the selected section 273 or sub-section of the datacapture definition file may be shown 274 as it would be shown to thedata capture user during the data capture process, ie. as it would beexecuted by the presentation layer 7 in real-time for the data captureuser. This enables the architect to test functionality and view exactlyhow the resulting form sections would appear to the end-user.

With reference to FIG. 28, the selected data capture definition file ispreferably first validated (using control box 280) against the formstandard 4. The validated document may then be exported using exportcontrol box 290, to destination address as specified at window 291, as aportable self-contained XML document 17 in proprietary format. The datacapture definition file 17 can be imported into the same or otherinstallation of the application 30 as required.

During import, as shown in FIG. 30, using import control box 300, theselected data capture definition document is first validated against theform standard 4 employed and then imported into the application'srepository 34 at the address indicated by window 301, where users canaccess it in the normal way.

The selected data capture definition file is first validated against theform standard 4 employed using validation control box 310 (FIG. 31) andthen released (release control box 320 in FIG. 32) as portableself-contained XML document 321 in the standard format employed where itcan be deployed for execution at the presentation layer 7—eg. on astand-alone desktop, on an online server/client browser environment,etc.

Permissions for a selected data capture definition file can be viewedand/or changed accordingly using a document permission propertiescontrol box 330 shown in FIG. 33.

Selected elements, sections or rules can be copied and pasted within orbetween data capture definition files using a copy/paste function. Theproperties of a selected section, element or rule can be viewed and/orchanged as required (providing the form is locked for edit).

A trigger dialog window 340 (FIG. 34) may be displayed showing allevents (triggers) which have rules assigned. The rule dialog window isdisplayed showing all rules, and provides a search function shown assearch control window 350 (FIG. 35).

A move up/down function may be provided to move a selected element,section or rule up or down within the same level in the data elementtree hierarchy.

When rules are copied between different forms or elements/sections aredeleted upon which rules were assigned to their events (triggers), therule can be considered as broken—that is it does not have a validassignment. To assist, a repair rule feature is available as shown inthe rule repair control box 360 in FIG. 36. This control box facilitatesthe identification and correction of invalid assignments.

Sections, elements and rules can be dragged and dropped within the samedata capture definition file or between data capture definition files.When dragging/dropping between the same file, the item is moved, whereaswhen the item is dragged/dropped between forms the item is copied.

In a make template function, the selected section or element becomes atemplate.

As discussed previously, once a data capture definition file 17 has beengenerated, this file may be executed by the presentation/execution layer7, which is platform independent, during a data capture process. Thepresentation/execution layer performs the function of displaying aplurality of visual displays, to a data capture user 18, that prompt theuser to enter data corresponding to each relevant data element in thedata capture definition file.

The layout of each visual display is determined, by thepresentation/execution layer, according to the logical relationshipbetween the sections, sub-sections and data elements which are definedby the hierarchical structure in the tree 101. The data capturedefinition file 17 does not contain any instructions relating toabsolute physical positioning of questions and prompts on the visualdisplays presented to the user during runtime of the data captureprocess. Only relative physical positioning of user prompts for dataelement capture, and the sequential progression of user prompts for dataelement capture are inferred from the data element hierarchical tree bythe presentation/execution layer.

As illustrated in FIGS. 37 and 38, respectively corresponding to astand-alone PC version of the presentation/execution layer 7, and aweb-based version, a first visual display 370 presents option boxprompts to the user for data input corresponding to a first section“number of applicants” of the data element tree. The prompts may bedisplayed either as click boxes 372 or as drop-down selection box 373,depending upon the application running the presentation/execution layer.FIGS. 39 and 40 illustrate corresponding user input screen for dataentry during the data capture process. In each case, the format andpositioning of each of the data input prompts 391 to 395 is determinedduring runtime of the data capture process according to the data elementhierarchy and data type.

For example, in the first applicant details user prompt display screen390, the data elements have equal status or level within thehierarchical tree within one sub-section, and are therefore displayedaccordingly by the presentation/execution layer 7 as a single column.

Similarly, the data capture process 7 detects that the data type for“title” 391 has a plurality of allowed values (Mr, Mrs, Ms, Dr etc) andtherefore interprets the user input prompt as a drop down menu.Similarly, the process detects that the data type for “Forenames” admitsof freeform text input of maximum length n characters, and provides anappropriate text input box 392. The “date of birth” element is detectedas data type “date” and is therefore presented as a date format inputbox 393.

It will be understood that the data capture process running on thepresentation/execution layer interprets the hierarchical data elementtree to determine that sections and certain sub-sections of data elementprompts should be presented on independent “pages” or screens, eachelement being afforded a presentation status dependent upon its rankingin the tree. Thus, user prompts for elements having a common sub-sectionare preferably presented in either column, row or matrix format witheach element prompt having equal “status” in the presented display. Theorder of the element prompts may be determined according to the sequenceof the elements in the tree. Prompts corresponding to separatesub-sections on a common display page may be incorporated withinseparate frames or separated by appropriate boundary structures.

Different sub-sections may be presented on separate display pages, or onthe same displays depending upon the number of data element promptsrequired, and the sizes of those prompts. The data capture process makesa determination, during runtime, of the best fit for each set of userprompts according to the size, content and complexity of the promptsrequired by the data capture definition file.

Because the layout of the form presented to the user is determinedduring runtime of the data capture process, the data capture process canmake allowance for the restrictions imposed by the user display in termsof screen size, display resolution, colour, availability of graphicsetc. Similarly, the data capture process can accommodate use of anysuitable available icons or graphics available for certain types of dataentry. For example, for date entry at prompt 393, only a procedure fornumeric keyboard entry might be available in FIG. 39, whereas in theweb-based version of FIG. 40, a separate procedure call for a date entrysubroutine 397 might be available.

In FIG. 41, a user display 410 of prompts 411 for input of datacorresponding to a series of “yes/no” data elements 412 of equal statuswithin a “general questions” section 413 is shown.

With reference to FIG. 42, the effects of rule-based actions defined inthe data capture definition file is shown in display 420. In thisdisplay, the user has selected the “yes” option 422 in response toprompt 421. As a consequence, this event fires a rule-based action todisplay a new user input button 423 to enable the collection of freetext notes regarding the previous response in a new user data entrywindow 424. FIGS. 43 and 44 illustrate corresponding events in aweb-based data capture process.

Upon completion of, or during, the data capture process, the data isverified by the presentation/execution layer 7 according to the dataverification specification contained in the data capture definition file17. Where conflicts with the data validation specification are found, analert window 450 is displayed to the user. This may take the form of ato-do list of items for correction, together with a diagnosis 451 of theerror.

Upon completion of the validation process by the presentation/executionlayer 7, a control box 461 in window 460 may offer the data capture userthe opportunity to accept and lock the completed form. FIGS. 47 and 48illustrate corresponding displays to FIGS. 45 and 46 in a web-browserbased implementation.

Other embodiments are within the scope of the appended claims.

1. Apparatus for automatically building an electronic form forpresentation to a user during a data capture process, comprising: meansfor generating a self-contained platform-independent data capturedefinition file specifying data elements required during data capture,each data element having a type specification and a logical relationshiprelative to other data elements in a hierarchical structure defined inthe data capture definition file, the means for generating the datacapture definition file further including means for enabling automaticbuilding of portions of said data capture definition file according to aform definition standard; and means for receiving as input the selfcontained platform-independent data capture definition file andautomatically generating a plurality of visual displays for presentationto a user during execution of a data capture process, each visualdisplay having an automatically determined form layout comprising aplurality of user input areas corresponding to the data elements, inwhich the form layout and physical positioning of the user input areason each display are determined, during runtime of the data captureprocess from information in the data capture definition file, in amanner corresponding to the defined logical hierarchical structure. 2.The apparatus of claim 1 wherein the data capture definition file is inXML format.
 3. The apparatus of claim 1 in which the data capturedefinition file further includes a functional specification of datavalidation operations to be performed in respect of at least some ofsaid data elements during execution of said data capture process, saidmeans for generating further including means for executing said datavalidation operations during said data capture process.
 4. The apparatusof claim 1 in which the data capture definition file further includes afunctional specification of rule-based actions to be taken duringexecution of the data capture process, said means for generating visualdisplays further including means for executing said rule-based actionsduring said data capture process, and determining successive visualdisplays for presentation to the user during the data capture processaccording to values of data captured and the rule-based actionsapplicable thereto.
 5. The apparatus of claim 4 wherein the means forgenerating the data capture definition file further includes means forincorporating said rule-based actions to be performed during executionof the data capture process, by a rule builder interface that enablesrule actions and conditions to be assigned to data capture events. 6.The apparatus of claim 1 in which the data capture definition filefurther includes a functional specification of a data model defining thebindings of data elements with an output message format.
 7. Theapparatus of claim 1 in which the data capture definition file furtherincludes a functional specification of data exchange requirementsaccording to the form definition standard.
 8. The apparatus of claim 1wherein the means for generating the data capture definition filefurther includes binding interface means for incorporating bindingdefinitions into said data capture definition file, each bindingdefinition defining the binding of a data element to a defined externaldata model.
 9. The apparatus of claim 1 further including means forensuring that said specification of data elements complies with the formdefinition standard.
 10. The apparatus of claim 1 further includingmeans for executing a data capture process, comprising: means forgenerating a succession of visual displays for presentation to a user,the physical layout of said visual displays being determined, duringexecution of the data capture process, according to the defined dataelements and their hierarchical structure in the data capture definitionfile, and according to process and display conditions prevailing in theplatform executing the data capture process.
 11. The apparatus of claim10 in which the means for executing the data capture process fun herincludes means for executing data validation operations according to afunctional specification of data validation operations defined in saiddata capture definition file.
 12. The apparatus of claim 10 in which themeans for executing the data capture process fun her includes means forexecuting rule-based actions according to a functional specification ofrule-based actions defined in said data capture definition file.
 13. Theapparatus of claim 10 in which the means for generating a succession ofvisual displays further comprises: means for inferring a relativephysical positioning of user prompts for data element capture and asequential progression of user prompts for data element capture from thedata capture definition file, and means for determining absolutephysical positioning of user prompts and presentation styles thereofaccording to criteria defined in the means for executing the datacapture process, and not the data capture definition file.
 14. Theapparatus of claim 1 in which the means for generating said data capturedefinition file and the means for generating visual displays operate ondifferent computing platforms.
 15. Apparatus for generating aself-contained platform-independent data capture definition file fordefining data elements required from a user during a data captureprocess, comprising: means for receiving as input a specification ofdata elements required during data capture, each data element having atype specification and a logical relationship relative to other dataelements in a hierarchical structure, said type specifications and saidhierarchical structure being usable for automatically determining aphysical layout of visual displays for presentation to a user during asubsequent data capture process; means for associating, with said dataelements, a set of data validation requirements for validating datacaptured in respect of each of the data elements; means for associating,with said data elements, a set of rules for execution during asubsequent data capture process, for further enabling automaticdetermination of a physical layout of the visual displays to bepresented to a user during said subsequent data capture process based onvalues of data captured during said data capture process; and means forgenerating said self-contained platform-independent data capturedefinition file defining said specification of data elements, saidhierarchical structure, said data validation requirements and said setof rules in a predetermined format for subsequent execution by a datacapture process, the means for generating said self-containedplatform-independent data capture definition file further includingmeans for enabling automatic building of portions of said data capturedefinition file according to a form definition standard.
 16. Theapparatus of claim 15 wherein the data capture definition file conformsto a standard that can be executed on a plurality of differentplatforms.
 17. The apparatus of claim 16 in which the data capturedefinition file is generated in XML format.
 18. The apparatus of claim15 further including means for incorporating, into said data capturedefinition file, a functional specification of data exchangerequirements according to the form definition standard.
 19. Theapparatus of claim 15 further including binding interface means forincorporating binding definitions into said data capture definitionfile, each binding definition defining the binding of a data element toa defined external data model.
 20. The apparatus of claim 15 furtherincluding means for ensuring that said specification of data elementscomplies with the form definition standard.
 21. The apparatus of claim15 further including means for assigning, to the data capture definitionfile, document ownership and execution rights.
 22. The apparatus ofclaim 15 further including means for generating at least a part of thedata capture definition file by automatic copying of a global template.23. The apparatus of claim 22 further including means for correlatingchanges made in global templates with relevant parts of data capturedefinition files that have been built using those templates.
 24. Theapparatus of claim 23 further including means for generating an impactanalysis report identifying potential consequences to relevant datacapture definition files resulting from a proposed change to a template.25. The apparatus of claim 15 further including a document validationmodule for ensuring compliance of a generated data capture definitionfile with at least one of a form definition standard, a functiondefinition standard and a data model standard.
 26. The apparatus ofclaim 14 in which the means for generating said data capture definitionfile further includes means for associating each data element with arespective section or sub-section in said logical hierarchicalstructure.
 27. Apparatus for automatically generating an electronic formfor presentation to a user during a data capture process, the apparatuscomprising: means for generating a self-contained platform-independentdata capture definition file in a predetermined format providing aspecification of data elements required during data capture, each dataelement having a type specification and a logical relationship relativeto other data elements in a hierarchical structure defined in the datacapture definition file, the means for generating the data capturedefinition file further including means for enabling automatic buildingof portions of said data capture definition file according to a formdefinition standard; and means for receiving as input the self containedplatform-independent data capture definition file and automaticallygenerating a plurality of visual displays for presentation to the user,each visual display having an automatically determined form layoutincluding a plurality of user input areas and user prompts relatingthereto corresponding to the data elements, in which the form layout andphysical positioning of the user input areas on each display aredetermined, during runtime of the data capture process from informationin the data capture definition file, in a manner corresponding to thedefined logical hierarchical structure.
 28. A computerized method ofautomatically building an electronic form for presentation to a userduring a data capture process, comprising: in a first computer process,generating a self-contained platform-independent data capture definitionfile specifying data elements required during data capture, each dataelement having a type specification and a logical relationship relativeto other data elements in a hierarchical structure defined in the datacapture definition file, wherein generating the data capture definitionfile includes automatic building of portions of said data capturedefinition file according to a form definition standard; and in a secondcomputer process, receiving as input the self-containedplatform-independent data capture definition file and automaticallygenerating a plurality of visual displays for presentation to a userduring execution of a data capture process, each visual display havingan automatically determined form layout comprising a plurality of userinput areas corresponding to the data elements, in which the form layoutand physical positioning of the user input areas on each display aredetermined, during runtime of the data capture process from informationin the data capture definition file, in a manner corresponding to thedefined logical hierarchical structure.
 29. A computerized method ofgenerating a self-contained platform-independent data capture definitionfile for defining data elements required from a user during a datacapture process, comprising: in a first computer process, receiving asinput a specification of data elements required during data capture,each data element having a type specification and a logical relationshiprelative to other data elements in a hierarchical structure, said typespecifications and said hierarchical structure being usable forautomatically determining a physical layout of visual displays forpresentation to a user during a subsequent data capture process; in asecond computer process, associating, with said data elements, a set ofdata validation requirements for validating data captured in respect ofeach of the data elements; in a third computer process, associating,with said data elements, a set of rules for execution during asubsequent data capture process, for further enabling automaticdetermination of a physical layout of the visual displays to bepresented to a user during said subsequent data capture process based onvalues of data captured during said data capture process; and in afourth computer process, generating said self containedplatform-independent data capture definition file defining saidspecification of data elements, said hierarchical structure, said datavalidation requirements and said set of rules in a predetermined formatfor subsequent execution by a data capture process, wherein generatingthe data capture definition file includes automatic building of portionsof said data capture definition file according to a form definitionstandard.
 30. A computerized method of generating an electronic form forpresentation to a user during a data capture process, comprising: in afirst computer process, generating a self contained platform-independentdata capture definition file in a predetermined format providing aspecification of data elements required during data capture, each dataelement having a type specification and a logical relationship relativeto other data elements in a hierarchical structure defined in the datacapture definition file, the means for generating the data capturedefinition file further including means for enabling automatic buildingof portions of said data capture definition file according to a formdefinition standard; in a second computer process, receiving as inputthe self-contained platform-independent data capture definition file andautomatically generating a plurality of visual displays for presentationto the user, each visual display having an automatically determined formlayout including a plurality of user input areas and user promptsrelating thereto corresponding to the data elements, in which the formlayout and physical positioning of the user input areas on each displayare determined, during runtime of the data capture process frominformation in the data capture definition file, in a mannercorresponding to the defined logical hierarchical structure.
 31. Acomputer program product, comprising a tangible computer readable mediumhaving thereon computer program code adapted, when said computer programcode is loaded onto a computer, to make the computer execute theprocedure of any one of claims 28 to
 30. 32. Apparatus for automaticallybuilding an electronic form for presentation to a user during a datacapture process, comprising: a data capture definition file generatorfor generating a self-contained platform-independent data capturedefinition file specifying data elements required during data capture,each data element having a type specification and a logical relationshiprelative to other data elements in a hierarchical structure defined inthe data capture definition file, the data capture definition filegenerator enabling automatic building of portions of said data capturedefinition file according to a form definition standard; and a visualdisplay generator coupled to receive the data capture definition filefor automatically generating a plurality of visual displays forpresentation to a user during execution of a data capture process, eachvisual display having an automatically determined form layout comprisinga plurality of user input areas corresponding to the data elements, inwhich the form layout and physical positioning of the user input areason each display are determined, during runtime of the data captureprocess from information in the data capture definition file, in amanner corresponding to the defined logical hierarchical structure. 33.Apparatus for generating a self-contained platform-independent datacapture definition file for defining data elements required from a userduring a data capture process, comprising: an input for receiving aspecification of data elements required during data capture, each dataelement having a type specification and a logical relationship relativeto other data elements in a hierarchical structure, said typespecifications and said hierarchical structure being usable forautomatically determining a physical layout of visual displays forpresentation to a user during a subsequent data capture process; a datacapture definition file generator for associating, with said dataelements, a set of data validation requirements for validating datacaptured in respect of each of the data elements and a set of rules forexecution during a subsequent data capture process, for further enablingautomatic determination of a physical layout of the visual displays tobe presented to a user during said subsequent data capture process basedon values of data captured during said data capture process, andgenerating said self-contained platform-independent data capturedefinition file defining said specification of data elements, saidhierarchical structure, said data validation requirements and said setof rules in a predetermined format for subsequent execution by a datacapture process the data capture definition file generator enablingautomatic building of portions of said data capture definition fileaccording to a form definition standard.
 34. Apparatus for generating anelectronic form for presentation to a user during a data captureprocess, the apparatus comprising: a data capture definition filegenerator for generating a self contained platform-independent datacapture definition file in a predetermined format providing aspecification of data elements required during data capture, each dataelement having a type specification and a logical relationship relativeto other data elements in a hierarchical structure defined in the datacapture definition file, the data capture definition file generatorenabling automatic building of portions of said data capture definitionfile according to a form definition standard; and a visual displaygenerator coupled to receive the data capture definition file forautomatically generating a plurality of visual displays for presentationto the user, each visual display having an automatically determined formlayout including a plurality of user input areas and user promptsrelating thereto corresponding to the data elements, in which the formlayout and physical positioning of the user input areas on each displayare determined, during runtime of the data capture process frominformation in the data capture definition file, in a mannercorresponding to the defined logical hierarchical structure.